Client had an outage where the Db went offline due to no disk space. Re-pointed DB and Logs to fresh drive with new folder and assigned permissions etc as per http://support.microsoft.com/kb/821915 Folder shows same priv1.edb and same size as source DB being copied - however no data is moved. Added to this nonsense, they lost the actual Blade on which the VHD sits and a DC. I'm thinking the best way now is to go the manual route and copy the EDB and STM offline While since i did this with 2003...any other advice? thx

My friend, I really want to help you, but I really don't understand what you're asking.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

My friend, I really want to help you, but I really don't understand what you're asking.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

On Tue, 21 Aug 2012 02:04:39 +0000, stuabroad wrote: >Client had an outage where the Db went offline due to no disk space. > >Re-pointed DB and Logs to fresh drive with new folder and assigned permissions etc as per http://support.microsoft.com/kb/821915 > >Folder shows same priv1.edb and same size as source DB being copied - however no data is moved. What, exactly, does that mean? If the EDB and STM files were moved then "data" was surely moved. The same is true of the log files. >Added to this nonsense, they lost the actual Blade on which the VHD sits and a DC. > >I'm thinking the best way now is to go the manual route and copy the EDB and STM offline Are you saying that, after you moved the databases, the databases were still in the original directory? That doesn't sound like the move completed. >While since i did this with 2003...any other advice? Providing more information would be a good start. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Tue, 21 Aug 2012 02:04:39 +0000, stuabroad wrote: >Client had an outage where the Db went offline due to no disk space. > >Re-pointed DB and Logs to fresh drive with new folder and assigned permissions etc as per http://support.microsoft.com/kb/821915 > >Folder shows same priv1.edb and same size as source DB being copied - however no data is moved. What, exactly, does that mean? If the EDB and STM files were moved then "data" was surely moved. The same is true of the log files. >Added to this nonsense, they lost the actual Blade on which the VHD sits and a DC. > >I'm thinking the best way now is to go the manual route and copy the EDB and STM offline Are you saying that, after you moved the databases, the databases were still in the original directory? That doesn't sound like the move completed. >While since i did this with 2003...any other advice? Providing more information would be a good start. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Perhaps spending 12 hours in front of a laptop yesterday decreased my written skills, for which i hold my hands up. 1. The storage on which both EDB and STM were placed went offline/lack of space. 2. Changing path to a new drive with more space allowed me to start the move process. 3. In the middle of the move process they then lost their entire Blade on which the server was placed, interrupting the DB move process. After the storage issues were fixed i still couldn't mount the DB. Obviously the move process stopped abruptly when the Blade also crashed. There were various events listed relating to being unable to find log files. In the end I was able to retain the original path(s) to the EDB and STM files, by dynamically expanding that Hyper-V disk. I was able to copy back the logs that had been moved BEFORE the blade crashed interrupting the move process and then remount the DB.

Glad you got your problem resolved. Thanks for reporting back.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Glad you got your problem resolved. Thanks for reporting back.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

On Tue, 21 Aug 2012 15:31:19 +0000, stuabroad wrote: > > >Perhaps spending 12 hours in front of a laptop yesterday decreased my written skills, for which i hold my hands up. > > > >1. The storage on which both EDB and STM were placed went offline/lack of space. > >2. Changing path to a new drive with more space allowed me to start the move process. > >3. In the middle of the move process they then lost their entire Blade on which the server was placed, interrupting the DB move process. Ahhh . . . WHEN that happened is the part that wasn't obvious from the first description of the problem. Timing is everything! :-) >After the storage issues were fixed i still couldn't mount the DB. Obviously the move process stopped abruptly when the Blade also crashed. There were various events listed relating to being unable to find log files. > >In the end I was able to retain the original path(s) to the EDB and STM files, by dynamically expanding that Hyper-V disk. Doing that first would have been faster than moving the data. Hindsight is a wonderful thing! >I was able to copy back the logs that had been moved BEFORE the blade crashed interrupting the move process and then remount the DB. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Tue, 21 Aug 2012 15:31:19 +0000, stuabroad wrote: > > >Perhaps spending 12 hours in front of a laptop yesterday decreased my written skills, for which i hold my hands up. > > > >1. The storage on which both EDB and STM were placed went offline/lack of space. > >2. Changing path to a new drive with more space allowed me to start the move process. > >3. In the middle of the move process they then lost their entire Blade on which the server was placed, interrupting the DB move process. Ahhh . . . WHEN that happened is the part that wasn't obvious from the first description of the problem. Timing is everything! :-) >After the storage issues were fixed i still couldn't mount the DB. Obviously the move process stopped abruptly when the Blade also crashed. There were various events listed relating to being unable to find log files. > >In the end I was able to retain the original path(s) to the EDB and STM files, by dynamically expanding that Hyper-V disk. Doing that first would have been faster than moving the data. Hindsight is a wonderful thing! >I was able to copy back the logs that had been moved BEFORE the blade crashed interrupting the move process and then remount the DB. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP